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I. REAL PARTY IN INTEREST 

The real party of interest is Motorola, Inc., a Delaware corporation. 

II. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences. 

III. STATUS OF CLAIMS 

This is an appeal from the final rejection of claims 1-21 of the above-referenced 
application. 

A. TOTAL NUMBER OF CLAIMS IN APPLICATION 

There are a total of 21 claims in the application. 

B. STATUS OF ALL THE CLAIMS 

1. Claims allowed: none 

2. Claims objected to: none 

3. Claims rejected: 1-21 

C. CLAIMS ON APPEAL 

The claims on appeal are 1-21 . It is important to note, however, that 

Applicants are not contesting the Examiner's rejections of claims 9 and 17-21 under 35 
U.S.C. 112, second paragraph. 

IV. STATUS OF AMENDMENTS 

No amendments have been filed subsequent to the Final Rejection. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Although specification citations are inserted below in accordance with C.F.R. 41.37, 
these reference numerals and citations are merely examples of where support may be 
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found in the specification for the terms used in this section of the brief. There is no intention 
to in any way suggest that the terms of the claims are limited to the examples in the 
specification. Although, as demonstrated by the reference numerals and citations below, 
the claims are fully supported by the specification as required by law, it is improper under 
the law to read limitations from the specification into the claims. Pointing out specification 
support for the claim terminology, as is done here to comply with rule 41 .37, does not in any 
way limit the scope of the claims to those examples from which they find support. Nor does 
this exercise provide a mechanism for circumventing the law precluding reading limitations 
into the claims from the specification. In short, the reference numerals and specification 
citations are not to be construed as claim limitations or in any way used to limit the scope of 
the claims. 

The claimed subject matter of independent claim 1 pertains to an interprocessor 
communication (IPC) network (100) that includes an IPC server (108) and one or more IPC 
clients (1 02-1 06) coupled to the IPC server (1 08), one of which is a requesting IPC client 
(102-106) (see FIGs. 1 and page 23, lines 8-10). In addition, the IPC server (108) includes 
an operational state table (2000) of the one or more IPC clients (1 02-1 06) (see FIG. 20 and 
page 24, lines 3-6). Upon receiving a service request from the requesting IPC client (102- 
106), the IPC server (108) determines which from amongst the one or more IPC clients 
(102-106) is best suited to handle the service request (see page 23, lines 10-21 and page 
24, line 22 to page 25, line 4). The requesting IPC client (102-106) determines whether to 
use the one or more IPC clients (102-106) recommended by the IPC server (108) (see page 
21 , line 20 to page 22, line 5). 

The claimed subject matter of independent claim 10 is directed to a method for 
providing intelligent targeting of nodes (102-106) in an IPC network (100) having one or 

CE11191JI210 
Page 4 of 18 



more nodes (102-106) (see FIGs. 1 and 19). The method can include the steps of receiving 
from one of the nodes (102-106) a service request at the IPC server (108) and determining 
which of the one or more nodes (102-106) can handle the service request (see steps 1902 
and 1904 of FIG. 19 and page 23, lines 8-13). The method can also include the step of 
selecting from one or more nodes (102-106) that have been determined to be able to 
handle the service request the best one to handle the service request using an operational 
state table (2000) located within the IPC server (108) (see step 1906 of FIG. 19; FIG. 20; 
and page 23, lines 1 3-21 ). The requesting node (1 02-1 06) determines whether to use the 
node (1 02-1 06) that was selected using the operational state table (2000) (see page 21 , 
line 20 to page 22, line 5). 

The claimed subject matter of independent claim 17 is directed to an IPC network 
(2100) having an IPC server (2100) and one or more clients (2102-2106) coupled to the IPC 
server (2100) (see FIG. 21 and page 25, lines 12-14). One of the one or more clients 
(2102-2106) has at least one client (2108, 21 10) coupled to the client (2102-2106) as a sub- 
client (2108, 2110) (see FIG. 21 and page 25, lines 14-15). The IPC server (2100) includes 
an operational state table (2000) that keeps track of the operational state of the one or more 
clients (2102-2106), and the IPC server (2100) provides the operational state table (2000) 
to the client (21 02-21 06) that has at least one sub-client (21 08, 21 1 0) coupled to the client 
(2102-2106) (see FIG. 21 and page 25, lines 15-23). 
VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1 and 10-16 are patentable under 35 U.S.C. 103(a) over U.S. Patent 
Application Publication No. 2003/0120782 to Bortoloso, et al. (Bortoloso) in view of U.S. 
Patent Application Publication No. 2004/0205767 to Partanen (Partanen) and further in view 
of U.S. Patent Application Publication No. 2002/0049842 to Huetsch, et al. (Huetsch). 
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Whether claims 2-8 are patentable under 35 U.S.C. 103(a) over Bortoloso, Partanen, 
Huetsch and further in view of U.S. Patent Application Publication No. 2005/0044162 to 
Liang, et al. (Liang). 

Whether claims 17-21 are patentable under 35 U.S.C. 103(a) over Bortoloso in view 
of Partanen and further in view of U.S. Patent No. 5,224,1 00 to Lee, et al. (Lee). 

Whether claim 9 is patentable under 35 U.S.C. 103(a) over Bortoloso, Partanen, 
Huetsch and Liang and further in view of Lee. 
VII. ARGUMENT 

A. The recitations of Bortoloso, Partanen and Huetsch do not render the invention of 
claims 1 and 10-16 unpatentable. 

(1) Claims 1, 10-13, 15 and 16 

A brief summary of the Bortoloso, Partanen and Huetsch references may be helpful. 
Bortoloso describes a client application (20) and a server application (21), each having 
dedicated inter-network service modules (22, 23) (see paragraph 0031). As correctly noted 
by the Examiner, Bortoloso does not teach the IPC server including an operational state 
table that keeps track of the operational state of the one or more IPC clients (see paragraph 
8, page 3 of the Final Office Action of June 9, 2006). The Examiner also concluded that 
Bortoloso does not describe the IPC server as determining which from amongst the one or 
more IPC clients is best suited to handle a service request upon receipt of a service from 
the requesting IPC client and the requesting IPC client determining whether to use the one 
or more IPC clients recommended by the IPC server (see paragraph 8, page 3 of the Final 
Office Action of June 9, 2006). 

Partanen describes a cluster of processing nodes (1, 2, 3) and a load balancer 
function that allocates tasks to the processing nodes (1 , 2, 3) according to predefined rules 
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(see FIG. 4 and paragraph 0003). The load balancer function divides the external load 
coming to the cluster of processing nodes (1 , 2, 3) in which a certain proportion of the 
external load is given to a particular node (see FIG. 4 and paragraphs 0003 and 0020). The 
Examiner concluded that Partanen does not teach the process of the requesting IPC client 
determining whether to use the one or more IPC clients recommended by the IPC server 
(see paragraph 8, page 4 the Final Office Action of June 9, 2006). 

Huetsch shows a load balancing system having a client (10) and a load balancer (12) 
for balancing for balancing a processing load in a network in which the processing load is 
generated by a plurality of clients (10) (see paragraph 0032). The system includes three 
processing servers (22, 24, 26) for servicing requests from the client (10) (see FIG. 3 and 
paragraph 0032). In addition, the load balancer (12) includes a selection program (60) for 
selecting at least one of the processing servers (22, 24, 26) in response to a request from 
the client (10) (see FIG. 3 and paragraph 0036). 

Independent claim 1 recites the feature of the requesting IPC client determining 
whether to use the one or more IPC clients recommended by the IPC server. Independent 
claim 10 recites similar subject matter. The Examiner agrees that this subject matter is not 
taught by the Bortoloso and Partanen references. Applicants, however, submit that 
Huetsch does not teach such a concept. In particular, the selection program (60) of the 
load balancer (12) selects at least one of the processing servers (22, 24, 26) in response to 
a client request, and Huetsch never mentions anything about the client (10) playing a role in 
determining which processing server (22, 24, 26) to use. In other words, Huetsch is no 
different from Partanen in this aspect, which the Examiner has clearly indicated does not 
read on the subject matter in contention here. The scheme of the present invention is far 
more flexible that what is described in these prior art references, an important characteristic 
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of an IPC network. 

(2) Claim 14 

Dependent claim 14 recites the subject matter of the IPC server determining whether 
a node specified by the requesting node cannot presently perform the requested service 
and the IPC server checking the operational state table periodically until the specified node 
is available to perform the service, at which point the IPC server informs the requesting 
node that the requested node is available to perform the service. Partanen does describe 
using a load share value as an indication of a possible problem in the node, in the 
configuration of software executing on the node or in the load balancing function itself (see 
paragraph 0046). Huetsch teaches that after the load balancer (12) selects an appropriate 
processing server (26), the load balancer (12) establishes a communication link (302) 
between the client (10) and the processing server (26) through load balancer (12) (see 
paragraph 0043). 

Applicants submit that the proposed combination of Partanen and Huetsch does not 
read on the subject matter of claim 14 recited above. In particular, neither reference 
describes a client requesting a specific node. The process described in Partanen to which 
the Examiner is referring (see paragraph 0046) merely explains that a load share value can 
be used in a trouble-shooting process and has nothing to do with monitoring a request from 
a client for a specific node to determine if the requested node is available to perform the 
requested service. Huetsch simply describes the process of establishing a link between a 
client and a processing server via a load balancer and never mentions anything about the 
active involvement of the client, i.e., all decisions are handled by the load balancer (12). 

B. The recitations ofBortoloso, Partanen, Huetsch and Liang do not render the 
invention of claims 2-8 unpatentable. 
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(1) Claims 2-4 and 6-8 

As noted above in Section A(1), Bortoloso, Partanen and Huetsch do not teach the 
requesting IPC client determining whether to use the one or more IPC clients recommended 
by the IPC server. As such, Applicants submit that claims 2-4 and 6-8 are patentable over 
these references. 

(2) Claim 5 

The subject matter recited in dependent claim 5 is similar to that in dependent claim 
14. As explained in Section A(2), Partanen and Huetsch simply do not teach the concept of 
an IPC client requesting a specific node to handle a service request and the IPC monitoring 
an operational state table to determine when the specifically-requested node can handle the 
service request. For this reason, Applicants believe that dependent claim 5 is patentable 
over the prior art. 

C. The recitations of Bortoloso, Partanen and Lee do not render the invention of 
claims 17-21 unpatentable. 

(1) Claims 17, 19-21 

Independent claim 17 recites the subject matter of the IPC server providing an 
operational state table to a client that has at least one sub-client coupled to the client. None 
of the prior art references cited by the Examiner teach this concept. 

In the Response to Arguments section of the Final Office Action of June 9, 2006, the 
Examiner explains that Bortoloso teaches the IPC server and IPC client as both using 
tables to store client and server information "such as connection state and physical state 
(pp. 0031-0032) and providing] the tables to the clients and to synchronizing the tables (pp. 
0031-0033)." 

A careful review of the paragraphs in Bortoloso cited by the Examiner here reveals 

CE11191JI210 
Page 9 of 18 



that when the client application (20) is initialized, the client application (20) is registered in 
its dedicated inter-network service module (22) by storing the client port ID in a virtual 
connection table (24) and storing the physical address of the corresponding connection 
path in a physical connection table (25) (see paragraphs 0031 and 0032). A similar process 
is performed for the server application (21) with its dedicated inter-network service module 
(23) (see paragraph 0033). The motive behind this process is to enable the client 
application (20) to send requests, such as a question (27), to the server application (21) 
(see paragraph 0035: "When the question 27 is processed a connection path is determined 
by accessing the virtual connection table 24 and the physical connection table 25 of the 
inter network service module 22."). 

This mere enablement of permitting the server application (21) to process requests 
from the client application (20) has nothing to do with the transfer of an operational state 
table from an IPC server to an IPC client. Moreover, there is simply no motivation, 
suggestion or teaching in Bortoloso or Partanen that would lead one of skill in the art to use 
the load share values of Partanen as part of the initialization of the client application (20) of 
Bortoloso. In fact, Bortoloso teaches away from such a combination in view of its use of 
dedicated inter-network service modules, as such components indicate that the client 
applications (20) will only communicate with the server application (21) and not with another 
client application (20). The ability of IPC clients in the present invention to readily 
communicate with one another is one reason why the operational state table can be 
provided from the IPC server to an IPC client. 

(2) Claim 18 

Dependent claim 18 recites the feature of the client that has the operational state 
table determining which client can handle a service request if one of the sub-clients sends a 
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service request message. In view of the discussion in section C(1 ), Applicants contend that 
none of the prior art references, either individually or in combination with one another, teach 
the IPC server providing the operational state table to the client that has a sub-client 
coupled to the client. Regarding the subject matter of claim 18, Applicants point out that the 
client application (20) of Bortoloso is never described as taking an active role in any 
decision-making process. The client application (20) merely provides service requests to 
the server application (21). Thus, Applicants submit that there is no suggestion or 
motivation for combining the load balancing function of Partanen with the client and server 
application configuration of Bortoloso and as such, that claim 18 is patentable over the prior 
art. 

D. The recitations of Bortoloso, Partanen, Huetsch, Liang and Lee do not render the 
invention of claim 9 unpatentable. 

Dependent claim 9 recites the feature of the IPC server sending the operational state 
table to the IPC client that has a sub-client coupled to the IPC client. As discussed in 
section C(1 ), Applicants believe that the cited prior art references, either individually or in 
combination with one another, teach such subject matter. As the subject matter here in 
claim 9 is similar, Applicants contend that the prior art references do not read on claim 9. 

Conclusion 

Because every element of the claimed invention is not disclosed by the cited prior art 
references, either individually or in combination with one another, Applicants submit that the 
claims on appeal are patentable. 

For the reasons set forth above, and as is apparent from a review of the above-cited 
references, the claims on appeal present patentable subject matter such that reversal of the 
rejection is appropriate. 
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VIII. CLAIMS APPENDIX 



1 . An Interprocessor Communication (IPC) network, comprising: 
an IPC server; 

one or more IPC clients coupled to the IPC server, one of which is a requesting 
IPC client; and 

the IPC server includes an operational state table which keeps track of the 
operational state of the one or more IPC clients, the IPC server upon receiving a 
service request from the requesting IPC client determines which from amongst 
the one or more IPC clients is best suited to handle the service request and the 
requesting IPC client determines whether to use the one or more IPC clients 
recommended by the IPC server. 

2. An IPC network as defined in claim 1, wherein the service request includes an 
opcode which informs the IPC server what service is being requested. 

3. An IPC network as defined in claim 2, wherein the IPC server upon receiving the 
opcode determines which from amongst the one or more IPC clients is capable of 
supporting the requested service. 

4. An IPC network as defined in claim 3, wherein the one or more clients send 
messages to the IPC server that are used by the IPC server to update the 
operational state table. 
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5. An IPC network as defined in claim 4, wherein the requesting IPC client can 
request a specific node to handle the service request and the IPC server will 
monitor the operational state table in order to determine when the specific node is 
available to handle the service request. 

6. An IPC network as defined in claim 4, wherein the IPC network is located within a 
radio communication device. 

7. An IPC network as defined in claim 4, wherein the messages sent by the one or 
more clients to the IPC server are sent periodically. 

8. An IPC network as defined in claim 4, wherein the messages sent by the one or 
more clients to the IPC server are sent after each of the one or more clients 
reaches a certain operational usage threshold level. 

9. An IPC network as defined in claim 4, wherein at least one of the one or more 
IPC clients has sub-clients coupled to the IPC client and the IPC server sends the 
operational state table to the IPC client. 

10. A method for providing intelligent targeting of nodes in an interprocessor 
communications (IPC) network having one or more nodes and an IPC server 
coupled to the one or more nodes, comprising the steps of: 

(a) receiving from one of the nodes a service request at the IPC server; 

(b) determining which of the one or more nodes can handle the service request; 
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(c) selecting from the one or more nodes that have been determined to be able to 
handle the service request in step (b) the best one to handle the service request 
using an operational state table located within the IPC server, wherein the 
requesting node determines whether to use the node that was selected using the 
operational state table. 

1 1 . A method as defined in claim 1 0, further comprising: 

(d) sending a message to the requesting node informing it which node will 
handle the service request. 

12. A method as defined in claim 10, wherein the operational table includes 
information regarding the current operational state of each of the one or more 
nodes, and the IPC server determines based on the operational state information 
which of the one or more nodes is best suited to perform the service being 
requested by the service request. 

13. A method as defined in claim 10, wherein the requesting node sending the 
service request of step (a) can specify which of the one or more nodes it wants to 
have perform the service, and the IPC server can determine if the specified node is 
currently available to handle the service request. 
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14. A method as defined in claim 13, wherein if the IPC server determines that the 
node specified by the requesting node can not presently perform the requested 
service, the IPC server will check the operational state table periodically until the 
specified node is available to perform the service, at which point the IPC server will 
send a message to the requesting node informing the requesting node that the 
requested node is available to perform the requested service. 

15. A method as defined in claim 10, wherein the one or more nodes periodically 
send messages to the IPC server which update the information in the operational 
state table. 

1 6. A method as defined in claim 1 0, wherein at least one of the one or more nodes 
sends a message to the IPC server which updates the information in the 
operational state table when it reaches a predetermined operational activity 
threshold level. 
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17. An Interprocessor Communication (IPC) network, comprising: 

an IPC server; 

one or more clients coupled to the IPC server, wherein one of the one or more 
clients has at least one client coupled to the client as a sub-client; and 

the IPC server includes an operational state table which keeps track of the 
operational state of the one or more clients, and the IPC server provides the 
operational state table to the client that has at least one sub-client coupled to the 
client. 

18. An IPC network as defined in claim 17, wherein if one of the at least one sub- 
clients sends a service request message, the client that has the operational state 
table determines which client can handle the service request. 

19. An IPC network as defined in claim 17, wherein the one or more clients send 
messages to the IPC servers which are used to update the operational state 
table. 

20. An IPC network as defined in claim 19, wherein the messages which are used to 
update the operational state table are sent periodically to the IPC server 
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21 . An IPC network as defined in claim 19, wherein the messages which are used to 
update the operational state table are sent by the one or more clients after each 
has reached a predetermined activity threshold level. 

EVIDENCE APPENDIX 

None 

RELATED PROCEEDINGS APPENDIX 

None 



CE11191JI210 
Page 18 of 18 



